Crash Course to UI, UX, and Product Design
What are UI, UX, and Product Design
How do they all differ? "Product design" is the term that encompasses the skills of both UI and UX design, but includes additional business strategy. Some folks might consider "product design" the phrase to refer to the designing of physical products.
In truth, all three are very similar (thus used interchangeably to those outside of the field):
A UI Designer is responsible for the visual designing of an interface. This includes basic design principles as well as animations, responsiveness, and interaction design.
A UX Designer is responsible for the strategic designing of a solution based around the customer experience (and sometimes referred to as "CX" as such). The skill-set here includes everything a UI designer does in addition to understanding usability heuristics, information architecture, content, and work flows.
A Product Designer is going to have all the skills a UX designer has, but will also have the business acumen to understand what drives adoption & conversion, retention, and growth of a product relative to the customer segment.
There are other types of design within technical spaces, too, like service design, industrial design, and more.
As a UX designer myself, I'll largely focus my knowledge on UI and UX design (but probably work to push you all into the strategy of UX for your job search benefits).
A deeper dive on UX:
The broad industry of User Experience (UX, CX) is rapidly growing. Within the UX field there are specialties ranging from accessibility designers and specialists (look up WCAG if you haven't yet!), UX Research (responsible for everything from desk research to conducting interviews, surveys, and running experiments), and UX content editing (leveraging a broad messaging strategy to implement the best messaging for customer understanding).
Another reason I focus on UX here is because ~80% of the time, if you're going to work in-house, there will be a prescriptive Design System. Design Systems do all the work of setting type, color, and UI element instantiation so that designers use the same library. This keeps the team working on Spotify's Podcast features similar to how Spotify's music features look, feel, and operate without working hard to collaborate. I have yet to meet someone who is just a UI designer for more than a few years, because you quickly understand the strategy behind UX and get to move beyond drag-and-dropping components to create pixel-perfect designs without getting to contribute to strategy (usability will always outweigh and outlast our visual delight, unfortunately).
So, how to pursue UX strategy in a semester? Let's look at the Double Diamond:
From Smashing Magazine: How to Run the Right Kind of Research Study with the Double-Diamond Model (https://www.smashingmagazine.com/2020/05/research-study-double-diamond-model/)
This visual is one of hundreds online conveying the same thing: the converging and diverging processes of UX and iterative problem solving. The "Start" spot requires an initial problem statement and some general hypotheses/assumptions about the problem. Moving left to right, you'll see from the Start spot you'll brainstorm many disjointed ideas (diverge) across your team to explore the problem. This is the "discovery" part of the Research diamond. After a set amount of time, you'll regroup, set focus, and narrow down the scope (converging) of what you want to do here. This is the "definition" phase of the Research diamond.
After you (and your team) have explored the problem and agree upon the proper scope, you'll have a revised problem statement and have alignment to start the next diverging exercise: designing. This "design" part of the second double diamond, the Design diamond, includes drafting and iterating. In order to iterate, you have to get feedback from not only internal stakeholders, but also customers, so this might be a great time for usability testing (it's like A/B testing but not in real life production). After however many design sprints your Product Manager will let you have, you'll walk away with confidence from your usability testing and explorations to agree upon a final solution. This leads you to the "deliver" part of the Design Diamond, and for UXers, it typically means just polishing and delivering the finished designs to your technical partners.
If this doesn't make sense, don't worry! There are tons of articles and resources online far more eloquent than myself. Heck, the Double Diamond even has its own Wikipedia page. The key takeaway here should be this, though: good UI/UX design starts with a LOT of research prior to even drafting a solution, and both the research and design are intended to be iterative phases wherein you are constantly going back and starting something new to maximize learning. A good 80% of our time at my job is in Discovery!
I'm going to put a pin in this right now, but I'll mark a break in the content for future additions. Please feel free to reach out to me with any questions! Or drop a comment and I can help share news for the rest of the students.
---------------------------------------------------------------------------------------------------------------------
Discovery Basics - Feb 19, 2024 Add
Discovering the Right Thing
I'm going to focus now on discovery and the role it plays in determining not only how, but what we design.
UX (and UI, subsequently) are nothing without Product viability. If your product is not marketable, there is no real way to measure usability or the customer impact. Think of it like this: you could have the best novel in the world, but if your agent can't sell any publisher on the plot... no one will get it. Literally, physically, it won't wind up in a reader's hands. Likewise, if your app or website has no purpose... no one will search for it. No one will download it.
UXers should live and die by metrics. Usability metrics can include time spent on task, average attempt rate, average completion rate, abandonment rates, etc. These metrics inform us of gaps in Products. If you go into industry, with the exception of going into a very young startup, you are likely not going to develop anything brand new and without any metrics to anchor your idea. Even if its an entirely new feature, your company will have some great insight already as to who it will be for and where it'll serve customers.
Product managers (not to be confused with a project manager) are responsible for understanding the needs of the business and understanding how customer desires/feedback should play into the strategy. As a PM's right-hand, it is important to know basic usability heuristics to help them strategize when there are a lot of options, but more importantly, knowing "we struggle with customers finishing this important task," vs. "we're seeing customers choose not to build their whole bio page," grows careers. "We struggle with customers finishing this important task," means customers are fundamentally unable to do the thing they want to do.
An important book to read for this strategic concept is Jobs to Be Done. This framework, widely used in tech Product, specifically in what I call Nouveau Product (think Silicon Valley darlings, FANG, etc.) highlights that there are needs a customer has when they interface with anything.
Take for example, doing taxes. If I work for a bank that manages a customer's investments and retirement accounts, the customer will need to login and view their year-end tax forms before they can go through and file their taxes. The Job to Be Done here is to get the files. But before the Job can be accomplished, the customer has to login, maybe authenticate with multi-factor authentication, navigate through the settings and dashboard, find the files, and download them. There are a lot of in-between things that build the experience around the Job to be done.
If you want to bake cookies, you have to have the ingredients. If you don't, all of a sudden your experience to bake cookies now includes going to the store. And maybe it includes cleaning the dishes. Who knows, maybe you have to clean the oven before you do that. All of these other things that are (disruptive) impediments are inevitable steps on the road to accomplishing the Job.
For this reason, it is really important to do Discovery. UXers have to fall in love not with the customer, but with the problem. If you can discover the true problem at the root of all the symptomatic pain points, you can truly make an impact. UXers are problem solvers. I liken it to a puzzle. Product says "We should have a picture of a cottage in the woods," while tech says "these are the pieces we have here. We've found some edge pieces (technical restraints (e.g. you can't ignore laws of physics))." It is up to the UXers to see the pieces, understand the informed business need, and then do the research to figure out what types of cottage in the woods people are expecting, like, and what is best to build within the business constraints. The metaphor falls apart here, but hopefully you can follow it...
When we talk about problems, too, we can't expect users to know their problems. Asking people "do you find traffic frustrating?" is unlikely to warrant any answer other than a "yes." But when we ask customers "Have you witnessed road rage? Are there specific times of day? What do you think contributes to dangerous road behaviors?" Are open ended questions likely to open a can of worms to go explore.
There is a oft-repeated quote in the design world: "The customer doesn't know what you want until you tell it what it wants." Likewise, there is a famous quote attributed to Ford: "If I asked people what they wanted, they'd have say 'a faster horse.'" Customers don't know the realm of what's possible when we get to focus on problems they don't even know about.
One quick way to explore if you have found a true problem for customers and not just a pain point (that might be symptomatic) is using the Five Why technique. With this technique you start with your initial problem/pain point statement, and then ask yourself "why? why did this happen? why is this true?" and then state the reason why. And then you do it again. And again. And again. By the time you've reached the fourth or fifth level of "but why?" you're probably 1. not ready to be around toddlers for another hour and 2. knee-deep in a heady problem statement that falls into the realm of a human psychological or sociological observation that causes a problem.
That might sound out of scope for what you think you should be doing, but this is what all Product design is. UX relies on the growing and trainable customer cognitive load. This is the concept of a user understanding how basic things operate and then not having to work to figure it out. It's why when I ask where a shopping cart might be on a website you'll know without a doubt it is on the upper right. It's why Instagram, Snapchat, LinkedIn, Facebook, and Reddit will all refresh their feed when you pull down from the top of it. These things were, at one point, new and foreign and not well known. But when paired with time, wide-adoption actually shifts the way people think and trains our customers.
This is a very powerful reality that should not be overlooked going into this field. Influence vs. manipulation can be discussed ad nauseam, but there is a known concept of "Dark Design," with a few basic executions you might be familiar with already. Dark Design is when a company (including us as designers) design an experience that manipulates the customer to act likely against their will--whether they realize it or not. For this reason, we should not overlook the basic truth about our work being as much psychology as it is a design craft (although, this is likely not a surprise to you as you've probably studied some human-computer interaction prior to this course).
With the power to influence behaviors of millions of people, we have to be strategic in how we solve problems. It requires knowing our customers and knowing our problem(s).
